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REMARKS 

Claims 1 through 12 remain in the application. No claim has yet been allowed. 

1 . The disclosure was objected to because of informalities, in particular with 
reference to the phrase at page 10, lines 21-22. This phrase has now been corrected. The 
Applicants have reviewed the remainder of the specification and have corrected other 
typographical errors. 

2. Fig. 4 was objected to as lacking a reference numeral "200". This reference 
numeral has now been added to the "proxy application" block which appears at the top of the 
replacement sheet enclosed herewith. 

3. Claims 1 through 3 were objected to because of various informalities. 
A comma has been added after the word "network" in Claim 1. 

It is believed that the phrase "at least one remote network accelerator" is now proper. 
The multiple parallel connections have now been clarified as being multiple transport 
layer connections referred to earlier in the claim. 

Claims 2 and 3 have been clarified as suggested by the Examiner. 

4. The Examiner rejected Claims 6-12 under 35 U.S.C. 1 12, second paragraph as being 
indefinite. The Examiner specifically requested that structure be added to the claim explaining 
what happens when packets are locally addressed. 

The Applicant has not amended these Claims because it is not legally necessary to do so. 
A claim does not have to recite all possible results or recite supposedly missing elements that are 
neither essential to nor necessary for practicing the Applicant's invention. See the Manual of 
Patent Examining Procedure, Section 2172.01 (a claim does not necessarily fail to comply with 
35 U.S.C. 112, second paragraph, where the recited elements serve independent purposes.) 

In the present case, the invention of Claim 6 has to do with processing packets that 
addressed to a destination that is not local, and then routing them in a specific way via a socket 
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interface. It does not matter to the invention what happens to packets addressed to a destination 
that is local They might be dropped or they might be routed to local destinations in other ways. 
But that is irrelevant. 

Further, an enablement rejection based on the grounds that a critical limitation is missing 
from a claim should be made only when the language of the specification indicates that the 
limitation is necessary for the invention to function as intended . Language in the disclosure, 
including the abstract, can rebut any argument of criticality. See MPEP 2164.08(c). 

Referring in particular to the specification at page 7, beginning at line 1 1 and continuing 
through line 28 or thereabouts, the invention concerns the situation when client machine A 
connected to a first local area network (LAN) 11-1 wishes to establish a connection with another 
client machine B in a second remote LAN 11-2 ( that is a machine that is not local) . A 
connection packet request is first transmitted from machine A to an accelerator, with the 
connection request specifying a port A and a port B for machine B. At the TCP level, the 
connection request may take the form of an SYN message. The accelerator has a proxy 
application that intercepts the connection request. Upon examining the destination address and 
the port specified in the intercepted request, the accelerator replies to machine A with a proxy 
acknowledgment in such a way as to fool machine A into thinking it is connected directly to 
machine B when in fact it is not. The specification then goes on to explain how a network 
accelerator 14-1 then may set up one or more active TCP connections as a proxy connection to 
the remote network accelerator 14-2. 

Thus it is clear the invention has to do with handling the traffic intended for a remote 
network. The invention does not concern the handling of local traffic. Thus, any claim element 
describing how local traffic is neither necessary nor required. 

Claims 9 and 10 have been amended to address the other concerns raised by the 
Examiner. 

5. Claims 1, 2 and 6-12 were rejected as being anticipated by Bartlett, et al., U.S. 
Patent Publication 2003/01 77396A1. 

Before discussing the prior art it will be instructive to continue the discussion of 
Applicants' invention. With Applicants' invention, a network accelerator 14 intercepts network 
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layer (e.g. IP packets), and requests that multiple transport layer connections (e.g., TCP layer 
connections) be established between the local network accelerator 14-1 and the remote network 
accelerator 14-2. Thus, packets associated with a single network layer connection are 
intercepted and routed on one of multiple transport layer TCP connections (sessions). A number, 
N, of parallel TCP connections are thus maintained between the network accelerators 14-1 and 
14-2, even when only a single network layer connection between nodes 10-1 and 10-2 is to be 
maintained. These multiple TCP connections are not spoofed in any manner. 

The present invention thus provides an architecture for increasing performance over a 
Wide Area Network (WAN). A proxy application in each network accelerator is responsible for 
establishing the multiple parallel Transmission Control Protocol (TCP) layer connections. A 
transmitted data stream for a given connection is thus divided or "striped" across the multiple 
parallel TCP connections. 

The multiple TCP connections may be opened over a single persistent physical layer 
(PHY) connection although if sufficient network resources are available, multiple PHY 
connections may also be used. See the specification as originally filed at pages 5 and 6. 

By increasing the number TCP connections implemented over a persistent physical layer 
connection, throughput is actually increased. This reduces the need for wait states since it is less 
likely that a specified TCP window size will be reached for a given desired through put. 

The invention may also use data compression techniques and a compression dictionary to 
process data streams belonging to a given connection. Typically, different streams of the same 
connection will have a common context. In this instance, the dictionary will be relevant to 
contribute to overall performance to all streams in that same connection. 

Turning attention now to the Bartlett publication, it does describe one way to improve 
network performance. In the Barlett approach, Virtual Private Network (VPN) peers are 
integrated with respective Performance Enhancement Proxying (PEP) peers. PEP peers 101 
intercepts a TCP connection packet and locally acknowledge that packet. It then transports the 
packet to its PEP peer 107 via a protocol which is designed to overcome or reduce the limitations 
of conventional TCP/IP networks. The optimize protocol is referred to as a "back bone 
protocol", and a "back bone connection" is used to connect the pair of PEP peers 101 and 107. 
[Bartlett, par. 0066] 
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In Bartlett's scheme, a TCP spoofing kernel 513 locally acknowledges data segments 
received from an DP host 301 . This allows the sending IP host 301 to send additional data 
immediately. As a result, this local sending of acknowledgments is said to allow the sending IP 
host to increase its TCP window size at a much faster rate than would supported if a normal end- 
to-end TCP connection were used. The TCP spoofing kernel 513 thus takes on the responsibility 
for reliable delivery of data that it has acknowledged over the backbone. [Barlett, par. 0098] 

Furthermore, it is said that in Bartlett's backbone protocol kernel 515, multiple TCP 
connections are multiplexed onto and carried by a single backbone connection. [Bartlett, par. 
0099] 

We thus see at least two important distinctions between the Bartlett approach and the 
Applicants' approach as now recited in the revised claims. 

First, the Applicants terminate the TCP connection on an end to end basis , e.g., 
Applicants' claimed invention requires operating two or more transport layer connections 
between the local accelerator and a remote accelerator. The Bartlett approach instead uses a TCP 
spoofing kernel 513 that locally acknowledge TCP packets. In other words, the present 
invention does not spoof TCP connections, it opens them end to end, requiring TCP layer 
acknowledgments from the far end. 

As a second distinguishing feature, the present involves breaking up a single network 
layer connection across multiple TCP connections - that is, Claim 1 requires "two or more 
transport layer connections" for a given network layer connection. This feature is also different 
from Bartlett's teaching, which is merely to provide multiple TCP connections over a single 
(physical layer) connection. 

There are several advantages to Applicants' approach. First, one can negotiate window 
sizes from the service side differently from those on the client side. This provides a distinct 
advantage. For example, if the client side requires a small data window, the server can have a 
larger window more appropriate for the server. 

Secondly, one does not have to worry about TCP sequence number synchronization with 
the Applicants' approach. This would have to be a included feature of any Barlett-like TCP 
spoofer, to ensure orderly packet delivery. 
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For these reasons, we believe Claim 1 and Claim 6 as amended are now allowable. 

Claims 3 through 5 were also rejected under 35 USC 103(a) as being unpatentable over 
Bartlett when combined with Dillon, U.S. Patent 6,658,463. Dillon does disclose dictionary 
based compression algorithms. While they are used in the context of a communication system, 
the addition of Dillon still does not render the claim obvious. As explained above, Bartlett does 
not anticipate all of the elements of Claim 1 as now amended. Thus Claim 3, which depends 
from amended Claim 1, should also be allowable. 

Furthermore, we point out that Claim 5 requires using a dictionary associated with an 
existing connection to be re-used to service a new connection. We can find no such feature 
suggested in Dillon at column 15, lines 35-48. That part of Dillon simply indicates that loss-less 
data compression algorithms, such as LZW, use a dictionary which is built up on both ends of a 
connection. Compression is achieved by sending a reference to the dictionary in place of an 
uncompressed string of bytes. The algorithm may automatically tune the dictionary as data is 
transferred so that the dictionary is well prepared to provide high compression should data 
similar to earlier previously transferred data be submitted for compression. 

However, that does not amount to a suggestion of sharing a common data dictionary 
across multiple connections. 

Claim 5 is this patentable for this further reason. 

6. An Information Disclosure Statement (IDS) is being filed concurrently herewith. Entry 
of that IDS is respectfully requested. 
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In view of the above amendments and remarks, it is believed that all claims are in 
condition for allowance, and it is respectfully requested that the application be passed to issue. If 
the Examiner feels that a telephone conference would expedite prosecution of this case, the 
Examiner is invited to call the undersigned. 



Respectfully submitted, 

HAMILTON, BROOK, SMITH & REYNOLDS, P.C. 




Registration No. 31,671 
Telephone: (978) 341-0036 
Facsimile: (978) 341-0136 



Concord, MA 01742-9133 
Dated: 
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Amendments to the Drawings 

Reference number 200 is being added to Fig. 4. Please refer to the attached marked up 
copy of the drawing. 
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